Finding ID | Version | Rule ID | IA Controls | Severity |
---|---|---|---|---|
V-265975 | ESXI-80-000248 | SV-265975r1003581_rule | Medium |
Description |
---|
When using a standard key provider, the ESXi host relies on vCenter Server to manage the encryption keys. When using a trusted key provider, the ESXi host relies directly on the Trust Authority Hosts for keys, and vCenter Server is not involved. Regardless of the type of key provider, the ESXi host obtains the keys initially and retains them in its key cache. If the ESXi host reboots, it loses its key cache. The ESXi host then requests the keys again, either from the key server (standard key provider), or the Trust Authority Hosts (trusted key provider). When the ESXi host tries to obtain keys and the key server is offline or unreachable, vTPMs, vSAN encryption, and VM encryption cannot function. In vSphere, encrypted workloads can continue to function even when the key server is offline or unreachable. If the ESXi host has a TPM, the encryption keys are persisted in the TPM across reboots. So, even if an ESXi host reboots, the host does not need to request encryption keys. Also, encryption and decryption operations can continue when the key server is unavailable, because the keys have persisted in the TPM. If the encryption features of vSphere are used, it is to protect the confidentiality of workloads and while key persistence protects the availability of the environment it does so at the cost of confidentiality. An organization must consider the physical security posture and key provider reliability in their environments and if the risk of physical loss of equipment outweighs the availability of the workloads. |
STIG | Date |
---|---|
VMware vSphere 8.0 ESXi Security Technical Implementation Guide | 2024-07-11 |
Check Text ( C-69898r1003579_chk ) |
---|
If the ESXi host does not have a compatible TPM, this is not applicable. From an ESXi shell, run the following command: # esxcli system security keypersistence get or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.security.keypersistence.get.invoke() If key persistence is enabled, this is a finding. |
Fix Text (F-69801r1003580_fix) |
---|
From an ESXi shell, run the following command: # esxcli system security keypersistence disable --remove-all-stored-keys or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.security.keypersistence.disable.CreateArgs() $arguments.removeallstoredkeys = $true $esxcli.system.security.keypersistence.disable.invoke($arguments) |